In #140 sinon gets updated while patching the code. While updating a package is not an issue, reviewing the package-lock.json is a pain in the ass and also a reviewer could be negligent and just merge without looking twice. So to avoid that we get some attack vector by a overlooked change in the package-lock.json we should absolutely not use package-lock.json

I am with you.

The biggest issue for me is that it causes package-lock changes to appear in random commits, which can lead to merge conflicts. It also can introduces security vulnerabilities.

https://snyk.io/blog/why-npm-lockfiles-can-be-a-security-blindspot-for-injecting-malicious-modules/

So +1 to remove it

@jorenvandeweyer what do you think?

But isn't security the very reason for lockfile, so there is no auto-install of new malicious packages that were hijacked and published? ALso does the lockfile show the dependencies integrity (sha512 sum) and I think we should rather think about a lockfile lint and accept lockfile updates only in combination with dependency version updates.

dependabot also uses package-lock.json so we should rather keep it and make sure nothing bad slips in.

in mongoose, we dont use package-lock.json and dependabot works as expected :)

@Uzlopak thank you for this hint. So, from my understanding we can basically "pin" versions in package.json instead, right!? I just checked the mongoose repo and saw this in package.json:

  "dependencies": {
    "bson": "^4.6.2",
    "kareem": "2.3.5",
    "mongodb": "4.5.0",
    "mpath": "0.9.0",
    "mquery": "4.0.3",
    "ms": "2.1.3",
    "sift": "16.0.0"
  },

All packages, besides bson are pinned. Is there a reason for bson not to be pinned? From my understanding, supply-chain attacks are possible (like that one with ua-parser), because of the unpinned versions (the carrot of trust, ^) causing automacic installation of a newly published, hijacked package. Therefore we should make all our versions in package.json fixed / pinned, and so should this bson be, too, right?

I just try to understand this, before simply copying this technique. From that point I would propose for this PR to pin all the versions of dependencies and devDependencies.

Strange. Will pin down the bson version in mongoose.

Lol nice, inadvertently found a small "bug" in mongoose.